Resource StructureDefinition/FHIR Server from package ForgePatientChart.0830#0.1.0 (93 ms)
Resources that use this resource
Resources that this resource uses
Source
{
"resourceType" : "StructureDefinition",
"id" : "profile-observation-vitals-patientchart",
"meta" : {
"versionId" : "4",
"lastUpdated" : "2022-08-23T14:14:25.4883389+00:00"
},
"url" : "http://telus.com/fhir/patientChart/StructureDefinition/profile-observation-vitals",
"name" : "ObservationVitals",
"title" : "Observation Vitals Patient Chart",
"status" : "draft",
"date" : "2021-03-01T20:13:35.2658231+00:00",
"description" : "Observations defined for use in the TELUS Patient Chart for conveying Vital Signs",
"fhirVersion" : "4.0.1",
"mapping" : [
{
"identity" : "workflow",
"uri" : "http://hl7.org/fhir/workflow",
"name" : "Workflow Pattern"
},
{
"identity" : "sct-concept",
"uri" : "http://snomed.info/conceptdomain",
"name" : "SNOMED CT Concept Domain Binding"
},
{
"identity" : "v2",
"uri" : "http://hl7.org/v2",
"name" : "HL7 v2 Mapping"
},
{
"identity" : "rim",
"uri" : "http://hl7.org/v3",
"name" : "RIM Mapping"
},
{
"identity" : "w5",
"uri" : "http://hl7.org/fhir/fivews",
"name" : "FiveWs Pattern Mapping"
},
{
"identity" : "sct-attr",
"uri" : "http://snomed.org/attributebinding",
"name" : "SNOMED CT Attribute Binding"
}
],
"kind" : "resource",
"abstract" : false,
"type" : "Observation",
"baseDefinition" : "http://hl7.org/fhir/StructureDefinition/Observation",
"derivation" : "constraint",
"differential" : {
"element" : [
{
"id" : "Observation",
"path" : "Observation",
"comment" : "Usage Note: For Blood Pressure, follow the structure https://build.fhir.org/bp.html, where we use the panel code https://loinc.org/85354-9/ and then specify systolic and diastolic components. We will use a data absent reason (unknown) if diastolic is not present. Mean blood pressure can be sent as a stand-alone observation or could be an additional component if calculated at the same time as BP. Examples of other components that may be recorded as part of the BP reading are: position with respect to gravity, anotomical site (left/right arm).\r\n\r\nUsed for simple observations such as device measurements, laboratory atomic results, vital signs, height, weight, smoking status, comments, etc. Other resources are used to provide context for observations such as laboratory reports, etc.",
"mustSupport" : true
},
{
"id" : "Observation.id",
"path" : "Observation.id",
"mustSupport" : true
},
{
"id" : "Observation.meta",
"path" : "Observation.meta",
"mustSupport" : true
},
{
"id" : "Observation.meta.lastUpdated",
"path" : "Observation.meta.lastUpdated",
"mustSupport" : true
},
{
"id" : "Observation.meta.source",
"path" : "Observation.meta.source",
"mustSupport" : true
},
{
"id" : "Observation.meta.profile",
"path" : "Observation.meta.profile",
"comment" : "Usage Note: This might be used during testing, when implementers wish to specify a more detailed HL7 vitals profile and test using the FHIR validator\r\n\r\nIt is up to the server and/or other infrastructure of policy to determine whether/how these claims are verified and/or updated over time. The list of profile URLs is a set.",
"mustSupport" : true
},
{
"id" : "Observation.text",
"path" : "Observation.text",
"comment" : "Usage Note: This should always be sent; there is no expectation that this will be there on the response.\r\n\r\nContained resources do not have narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a \"text blob\" or where text is additionally entered raw or narrated and encoded information is added later.",
"mustSupport" : true
},
{
"id" : "Observation.identifier",
"path" : "Observation.identifier",
"comment" : "Usage Note: A universal identifier (PLAC or FILL) must be present when known. By example, if the originating system was a lab and the lab results includes an identifier this must be sent..",
"max" : "1"
},
{
"id" : "Observation.status",
"path" : "Observation.status",
"comment" : "Usage Note: For labs, a mapping of preliminary and final are common and can be mapped within the EMR. 99.9% of the cases, final is the correct value but in rare cases another value may be more appropriate.\r\n\r\nEMR Mapping spreadsheet\r\nPSS: 99% of time this will be set to final\r\nMA: Coding is mixed; \r\nFHIR->MA\r\nregistered-> LL - Registered means that the lab has it but waiting on a result; typiclly only used inside the lab\r\npreliminary->preliminary\r\nfinal->Final\r\namended->Corrected?\r\n->cancelled\r\n->incomplete\r\n->not done\r\n->partial\r\n->received\r\n->stored\r\n->booked\r\n->done\r\n-> pending \r\n\r\nThis element is labeled as a modifier because the status contains codes that mark the resource as not currently valid.",
"mustSupport" : true
},
{
"id" : "Observation.category",
"path" : "Observation.category",
"comment" : "EMR API - Category\r\nMA: TBC\r\nPSS: \r\nMS: Can be derived\r\n\r\nIn addition to the required category valueset, this element allows various categorization schemes based on the owner’s definition of the category and effectively multiple categories can be used at once. The level of granularity is defined by the category concepts in the value set.",
"min" : 1,
"max" : "1",
"fixedCodeableConcept" : {
"coding" : [
{
"system" : "http://terminology.hl7.org/CodeSystem/observation-category",
"code" : "vital-signs"
}
]
},
"mustSupport" : true
},
{
"id" : "Observation.category.coding",
"path" : "Observation.category.coding",
"mustSupport" : true
},
{
"id" : "Observation.category.text",
"path" : "Observation.category.text",
"mustSupport" : true
},
{
"id" : "Observation.code",
"path" : "Observation.code",
"comment" : "**Terminology: May wish to create a TELUS value set and add missing values, eg HIP measurement, Waist measurement, etc; import FHIR vitals plus the newbies\r\n\r\nUsage Rule: Additonal Codings are allowed in Observation.code- e.g. more specific LOINC Codes, SNOMED CT concepts, system specific codes. \r\nExample: For weight, the LOINC code of 29463-7 must be specified and an additional code of 8339-4, \"Birth Weight Measured\" may also be sent.\r\n\r\nConformance Rule: The local code must always be sent for codified values. \r\nTBC - Usage Note: If the same observation code is documented several times the the POS, it must be sent multiple times.\r\n\r\nUsage: LOINC (example)\r\nhttp://hl7.org/fhir/ValueSet/observation-codes >1000 codes\r\nMA: loinc (most common), ICD-9, snomed,type code, atc class, workload, and no codes as well\r\nPSS: PSS: Custom codes may not have a code and only text would be conveyed. H for standard vitals\r\nMS: PCLOCD, ICD-10\r\n\r\n*All* code-value and, if present, component.code-component.value pairs need to be taken into account to correctly understand the meaning of the observation.",
"mustSupport" : true,
"binding" : {
"strength" : "extensible",
"valueSet" : "http://hl7.org/fhir/ValueSet/observation-vitalsignresult"
}
},
{
"id" : "Observation.code.coding",
"path" : "Observation.code.coding",
"comment" : "Usage Note: There is an expectation that you must always send the high level LOINC code; a second coding should be present to represent the \"reported\" LOINC value. Example: this could occur when a value is extracted from a specialist report and sent as a \"reported\" observation rather than a measured observation.\r\n\r\nCodes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.",
"mustSupport" : true
},
{
"id" : "Observation.code.coding.system",
"path" : "Observation.code.coding.system",
"min" : 1,
"mustSupport" : true,
"binding" : {
"strength" : "preferred",
"valueSet" : "http://loinc.org"
}
},
{
"id" : "Observation.code.coding.code",
"path" : "Observation.code.coding.code",
"min" : 1,
"mustSupport" : true
},
{
"id" : "Observation.code.text",
"path" : "Observation.code.text",
"comment" : "Usage Note: Text is mandatory as it is important to convey exactly what the clinican entered or selected. Example: Weight will often have further meaning such as Pre-Pregnancy Weight, Discharge Weight, Birth weight, current weight, etc.\r\n\r\nTBC - If height is recorded as 6'2, do we want it here? or should we capture specifically with the quantity?\r\n\r\nVery often the text is the same as a displayName of one of the codings.",
"min" : 1,
"mustSupport" : true
},
{
"id" : "Observation.subject",
"path" : "Observation.subject",
"min" : 1,
"type" : [
{
"code" : "Reference",
"targetProfile" : [
"http://hl7.org/fhir/StructureDefinition/Patient"
],
"aggregation" : [
"bundled"
]
}
],
"mustSupport" : true
},
{
"id" : "Observation.subject.reference",
"path" : "Observation.subject.reference",
"mustSupport" : true
},
{
"id" : "Observation.subject.display",
"path" : "Observation.subject.display",
"comment" : "Usage Note: This should contain the name of the Patient, which can then be used in narrative where applicable\r\n\r\nThis is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it.",
"mustSupport" : true
},
{
"id" : "Observation.focus",
"path" : "Observation.focus",
"comment" : "FDG/Jim - we don't think we need to support this; convey via text. System likely do not support a separate field for fetus; we would need to infer from coding?\r\n\r\nTypically, an observation is made about the subject - a patient, or group of patients, location, or device - and the distinction between the subject and what is directly measured for an observation is specified in the observation code itself ( e.g., \"Blood Glucose\") and does not need to be represented separately using this element. Use `specimen` if a reference to a specimen is required. If a code is required instead of a resource use either `bodysite` for bodysites or the standard extension [focusCode](extension-observation-focuscode.html)."
},
{
"id" : "Observation.effective[x]",
"path" : "Observation.effective[x]",
"comment" : "Usage: Mandatory when sending data and must be a dateTime. \r\n\r\nEMRAPI - effectiveDateTime\r\nEffective period, instant and timing are removed as DTs; not supported by EMRs or API\r\n\r\nAt least a date should be present unless this observation is a historical report. For recording imprecise or \"fuzzy\" times (For example, a blood glucose measurement taken \"after breakfast\") use the [Timing](datatypes.html#timing) datatype which allow the measurement to be tied to regular life events.",
"type" : [
{
"code" : "dateTime"
}
],
"mustSupport" : true
},
{
"id" : "Observation.performer",
"path" : "Observation.performer",
"mustSupport" : true
},
{
"id" : "Observation.performer.reference",
"path" : "Observation.performer.reference",
"comment" : "Discussion requried - if this is important, we can maybe work this out \r\n\r\nUsing absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading across closed eco-system boundaries. Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. If the URL conforms to the structure \"/[type]/[id]\" then it should be assumed that the reference is to a FHIR RESTful server.",
"mustSupport" : true
},
{
"id" : "Observation.performer.display",
"path" : "Observation.performer.display",
"mustSupport" : true
},
{
"id" : "Observation.value[x]",
"path" : "Observation.value[x]",
"comment" : "???????????????/ still thinking - can the text go in value as an extension? is it captured this way or should this be part of \"Note\" associated with the entire observation?\r\n\r\nANNE - add text value for weight profile to record \"6'2\" - which is then convered\r\nHeight - typically three ways to measure: eg 172cm = inches = 68 and = feet and inches - 5'8\" or 5ft 8in. This will be conveyed as quanity.text (extension).\r\nWeight - 5lb 3oz, or 5'3\" \r\n\r\nConformance Rule: If no value is present, a dataAbsentReason should be populated.\r\n\r\nEMRAPI - valueQuantity\r\nEMRAPI: valueString - PSS: BP is extracted as a value string after the colon. Syntax is BP: value or T: value\r\nEMRAPI: valueDateTime\r\nEMRAPI: valueBoolean\r\nInteger and Range are not supported in the API\r\nVitals will always be quantities - ANNE CHECK HL7 PROFILE\r\nValue string is used for Blood Pressure\r\n\r\nPSS: Unit of valueQuantity is not extracted therefor confidence is 'L'. In PSS unless otherwise specified all units are assumed to be kg.\r\nMS: \r\n\r\nDiscussion: confirm if we take anythign out of scope or leave it for future; \r\n\r\nJason/Anne - add UCUM - as mandatory\r\n\r\nAn observation may have; 1) a single value here, 2) both a value and a set of related or component values, or 3) only a set of related or component values. If a value is present, the datatype for this element should be determined by Observation.code. A CodeableConcept with just a text would be used instead of a string if the field was usually coded, or if the type associated with the Observation.code defines a coded value. For additional guidance, see the [Notes section](observation.html#notes) below.",
"type" : [
{
"code" : "Quantity"
}
],
"mustSupport" : true
},
{
"id" : "Observation.dataAbsentReason",
"path" : "Observation.dataAbsentReason",
"comment" : "Usage Note: Use a value of \"unknown\" where diastolic would normally be present but is not stored in the EMR.\r\n\r\nNull or exceptional values can be represented two ways in FHIR Observations. One way is to simply include them in the value set and represent the exceptions in the value. For example, measurement values for a serology test could be \"detected\", \"not detected\", \"inconclusive\", or \"specimen unsatisfactory\". \n\nThe alternate way is to use the value element for actual observations and use the explicit dataAbsentReason element to record exceptional values. For example, the dataAbsentReason code \"error\" could be used when the measurement was not completed. Note that an observation may only be reported if there are values to report. For example differential cell counts values may be reported only when > 0. Because of these options, use-case agreements are required to interpret general observations for null or exceptional values.",
"mustSupport" : true
},
{
"id" : "Observation.dataAbsentReason.coding",
"path" : "Observation.dataAbsentReason.coding",
"min" : 1,
"max" : "1",
"mustSupport" : true
},
{
"id" : "Observation.dataAbsentReason.coding.system",
"path" : "Observation.dataAbsentReason.coding.system",
"min" : 1
},
{
"id" : "Observation.dataAbsentReason.coding.code",
"path" : "Observation.dataAbsentReason.coding.code",
"min" : 1,
"mustSupport" : true
},
{
"id" : "Observation.dataAbsentReason.text",
"path" : "Observation.dataAbsentReason.text",
"comment" : "Usage note: This is used in the Observation.text instead of the code.\r\n\r\nVery often the text is the same as a displayName of one of the codings."
},
{
"id" : "Observation.interpretation",
"path" : "Observation.interpretation",
"comment" : "Usage Note: This is not supported in PSS; MA, MS for vitals as a discrete data element; this information would be buried in text. \r\nIf the EMR has this in an accessible manner, eg on custom forms such as a Chronic Disease Management forms this may be included.\r\n\r\nHistorically used for laboratory results (known as 'abnormal flag' ), its use extends to other use cases where coded interpretations are relevant. Often reported as one or more simple compact codes this element is often placed adjacent to the result value in reports and flow sheets to signal the meaning/normalcy status of the result."
},
{
"id" : "Observation.note",
"path" : "Observation.note",
"comment" : "Usage Note: This will be supported by MA as there is a single note per vital. PSS does not have a vital note and therefore cannot support this; in PSS, this is entered in context of an encounter note. MS have a single note shared across multiple vitals; may attach the note to all vitals.\r\n\r\nConformance Rule: Must be displayed to recipient.\r\n\r\nEMRAPI: notes\r\n\r\nMay include general statements about the observation, or statements about significant, unexpected or unreliable results values, or information about its source when relevant to its interpretation.",
"mustSupport" : true
},
{
"id" : "Observation.note.time",
"path" : "Observation.note.time",
"mustSupport" : true
},
{
"id" : "Observation.note.text",
"path" : "Observation.note.text",
"mustSupport" : true
},
{
"id" : "Observation.bodySite",
"path" : "Observation.bodySite",
"comment" : "EMRAPI: not supproted\r\nPSS does have custom user created stamps but as these are customized they aren't reliable as discrete data. MA does not support this today.\r\nOnly used if not implicit in code found in Observation.code. In many systems, this may be represented as a related observation instead of an inline component. \n\nIf the use case requires BodySite to be handled as a separate resource (e.g. to identify and track separately) then use the standard extension[ bodySite](extension-bodysite.html)."
},
{
"id" : "Observation.bodySite.text",
"path" : "Observation.bodySite.text",
"mustSupport" : true
},
{
"id" : "Observation.referenceRange",
"path" : "Observation.referenceRange",
"comment" : "Usage Note: Some EMRs (eg MA) will have the ability to specify the reference range on a vital. This is rare but will be sent if it has been specified. \r\n\r\n\r\nMost observations only have one generic reference range. Systems MAY choose to restrict to only supplying the relevant reference range based on knowledge about the patient (e.g., specific to the patient's age, gender, weight and other factors), but this might not be possible or appropriate. Whenever more than one reference range is supplied, the differences between them SHOULD be provided in the reference range and/or age properties.",
"mustSupport" : true
},
{
"id" : "Observation.referenceRange.low",
"path" : "Observation.referenceRange.low",
"mustSupport" : true
},
{
"id" : "Observation.referenceRange.high",
"path" : "Observation.referenceRange.high",
"mustSupport" : true
},
{
"id" : "Observation.referenceRange.text",
"path" : "Observation.referenceRange.text",
"mustSupport" : true
},
{
"id" : "Observation.component",
"path" : "Observation.component",
"requirements" : "Usage: For BP, the panel code of https://loinc.org/85354-9 can be used; with components to specifiy systolic and diastolic components. Use a data absent reason if diastolic is not present. Alignment: This aligns with the base FHIR profile: https://build.fhir.org/bp.html\r\n\r\nMRAPI: *.component\r\nMS: Patient Summary-> Clinical Data -> vital signs->blood pressure\r\nPSS: BP comes back as a valueString but we can derive componebt by parsing the string. Systolic is numerator and diastolic is the denominator.\r\nMA: ???\r\n\r\n\r\nComponent observations share the same attributes in the Observation resource as the primary observation and are always treated a part of a single observation (they are not separable). However, the reference range for the primary observation value is not inherited by the component values and is required when appropriate for each component observation.",
"mustSupport" : true
},
{
"id" : "Observation.component.code",
"path" : "Observation.component.code",
"comment" : "EMRAPI: *.component.code\r\nLOINC (example)\r\nhttp://hl7.org/fhir/ValueSet/observation-codes\r\n1000+ codes\r\nMA: \r\nPSS:\r\nMS: Does not support \"mean blood pressure\". What happens when receiving this data?\r\n\r\nUsage Rule: Send th preferred code where possible; alway include a local code when available and minimally text\r\n\r\n*All* code-value and component.code-component.value pairs need to be taken into account to correctly understand the meaning of the observation.",
"mustSupport" : true,
"binding" : {
"strength" : "example",
"valueSet" : "http://hl7.org/fhir/ValueSet/observation-vitalsignresult"
}
},
{
"id" : "Observation.component.code.coding",
"path" : "Observation.component.code.coding",
"mustSupport" : true
},
{
"id" : "Observation.component.code.coding.system",
"path" : "Observation.component.code.coding.system",
"mustSupport" : true
},
{
"id" : "Observation.component.code.coding.code",
"path" : "Observation.component.code.coding.code",
"mustSupport" : true
},
{
"id" : "Observation.component.code.coding.display",
"path" : "Observation.component.code.coding.display",
"mustSupport" : true
},
{
"id" : "Observation.component.code.text",
"path" : "Observation.component.code.text",
"min" : 1,
"mustSupport" : true
},
{
"id" : "Observation.component.value[x]",
"path" : "Observation.component.value[x]",
"comment" : "EMRAPI: *.component.valueQuantity\r\nEMRAPI: *.component.valueString\r\nEMRAPI: does not support dateTime or Integers\r\nMA: only numerics are allowed\r\n\r\nRules for receiving \r\n\r\nConformance Rule: For blood pressure - o\r\n\r\nUsed when observation has a set of component observations. An observation may have both a value (e.g. an Apgar score) and component observations (the observations from which the Apgar score was derived). If a value is present, the datatype for this element should be determined by Observation.code. A CodeableConcept with just a text would be used instead of a string if the field was usually coded, or if the type associated with the Observation.code defines a coded value. For additional guidance, see the [Notes section](observation.html#notes) below.",
"mustSupport" : true
},
{
"id" : "Observation.component.dataAbsentReason",
"path" : "Observation.component.dataAbsentReason",
"mustSupport" : true
},
{
"id" : "Observation.component.dataAbsentReason.coding",
"path" : "Observation.component.dataAbsentReason.coding",
"min" : 1,
"max" : "1",
"mustSupport" : true
},
{
"id" : "Observation.component.dataAbsentReason.coding.system",
"path" : "Observation.component.dataAbsentReason.coding.system",
"min" : 1,
"fixedUri" : "http://terminology.hl7.org/CodeSystem/data-absent-reason",
"mustSupport" : true
},
{
"id" : "Observation.component.dataAbsentReason.coding.code",
"path" : "Observation.component.dataAbsentReason.coding.code",
"min" : 1,
"mustSupport" : true
},
{
"id" : "Observation.component.interpretation",
"path" : "Observation.component.interpretation",
"comment" : "EMRAPI: Interpretation\r\nUsage Notes: This is used for lab results\r\n\r\nHistorically used for laboratory results (known as 'abnormal flag' ), its use extends to other use cases where coded interpretations are relevant. Often reported as one or more simple compact codes this element is often placed adjacent to the result value in reports and flow sheets to signal the meaning/normalcy status of the result."
},
{
"id" : "Observation.component.interpretation.coding",
"path" : "Observation.component.interpretation.coding",
"mustSupport" : true
},
{
"id" : "Observation.component.interpretation.coding.system",
"path" : "Observation.component.interpretation.coding.system",
"min" : 1,
"mustSupport" : true
},
{
"id" : "Observation.component.interpretation.coding.code",
"path" : "Observation.component.interpretation.coding.code",
"min" : 1,
"mustSupport" : true
},
{
"id" : "Observation.component.interpretation.coding.display",
"path" : "Observation.component.interpretation.coding.display",
"min" : 1,
"mustSupport" : true
},
{
"id" : "Observation.component.interpretation.text",
"path" : "Observation.component.interpretation.text",
"mustSupport" : true
},
{
"id" : "Observation.component.referenceRange",
"path" : "Observation.component.referenceRange",
"comment" : "EMRAPI: referenceRangeLow, referenceRangeHigh\r\nUsage: This is supported for lab; but not often used for vitals. Some EMRs will allow for this\r\n\r\nMost observations only have one generic reference range. Systems MAY choose to restrict to only supplying the relevant reference range based on knowledge about the patient (e.g., specific to the patient's age, gender, weight and other factors), but this might not be possible or appropriate. Whenever more than one reference range is supplied, the differences between them SHOULD be provided in the reference range and/or age properties.",
"contentReference" : "http://hl7.org/fhir/StructureDefinition/Observation#Observation.referenceRange",
"mustSupport" : true
},
{
"id" : "Observation.component.referenceRange.low",
"path" : "Observation.component.referenceRange.low",
"mustSupport" : true
},
{
"id" : "Observation.component.referenceRange.high",
"path" : "Observation.component.referenceRange.high",
"mustSupport" : true
}
]
},
"text" : {
}
}
XIG built as of ??metadata-date??. Found ??metadata-resources?? resources in ??metadata-packages?? packages.
FHIR